Develop a FHIR data model
Develop a FHIR data model to communicate the data design
Data models help people understand what information is being collected and managed and how it relates to other data in existing systems/applications.
A FHIR data model can be used to effectively illustrate how FHIR resources are used and extended to represent information in a particular solution domain, and how related data in existing systems is referenced.
FHIR API designer/developers should consider use of a FHIR data model to illustrate data features and aspects such as:
- The key FHIR resource datatypes, and whether these are standard or extended (profiled),
- The important FHIR references which need to exist between the resources,
- The boundaries of FHIR data management showing where references exist to data managed in other external systems,
- Data elements that are extensions to FHIR,
- Shared definitional resources which are expected to be configured as part of the ecosystem.
FHIR data model
The following diagram is suggested to API designers/developers as an example of how to represent a FHIR data model.
It is intended to be a one-page entity-relationship diagram and uses UML 2.0 class diagram notation.
Health NZ has found that these kinds of diagrams can easily be created and managed using plantuml which is a free language for diagram creation. This enables the plantuml diagram source code to be version-controlled and shared, and diagrams can easily be generated on-demand for incorporation into Implementation Guides, websites or Confluence pages.
Detailed description of figure
The diagram in this guideline is an example of how to represent a FHIR data model. It is an entity-relationship diagram using UML 2.0 class diagram notation. The example data model shows the main FHIR resource types as entities, with key FHIR references between instances of these types are depicted as relationships. Health NZ recommends that creating these kinds of diagrams using plantuml code (the plantuml code for this example is also on this page) which enables the diagram source to be version-controlled and shared, and diagrams easily incorporated into Implementation Guides, websites or Confluence pages. Here is an overview of three key features of the diagram notation. Firstly frames: Frames on the diagram show *bounded contexts* or logical domains of data management. Secondly entities: Entities show the key data types of the model. Entities are named by their **FHIR resource type** or name of a profile if this applies. Each entity has a UML stereotype which is the base FHIR resource type of that entity. Entities are colour-coded to distinguish standard FHIR resources from profiled resources. And finally relations: Relations in the model represent FHIR resource references. Cardinality of each relationship is shown using crowsfoot notation. Solid lines are used for FHIR relative literal references between resources within a bounded context, whereas dotted blue lines are used for FHIR logical identifier references to a resource in another system context, for example an NHI reference. If an arrow is present this indicates the direction of the FHIR reference from source to target.